Independent Submission K. Meadors, Ed. 
Request for Comments: 6017 Drummond Group Inc. 
Category: Informational September 2010 
ISSN: 2070-1721 


Electronic Data Interchange - Internet Integration (EDIINT) 
Features Header Field 


Abstract 


With the maturity of the Electronic Data Interchange - Internet 
Integration (EDIINT) standards of AS1, AS2, and AS3, applications and 
additional features are being built upon the basic secure transport 
functionality. These features are not necessarily supported by all 
EDIINT applications and could cause potential problems with 
implementations. The EDIINT-Features header field provides a means 
to resolve these problems and support new functionality. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6017. 


Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. 
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1. Introduction 


EDIINT applications provide for a secure means of payload document 
transport. The original intent was for transport of a single EDI or 
XML document. However, as AS1 [RFC3335], AS2 [RFC4130], and AS3 
[RFC4823] matured, other features and application logic were 
implemented upon EDIINT standards. Since these features go beyond 
(but do not violate) the basic premise of EDIINT, a means is needed 
to communicate to trading partners features that are supported by the 
originating user agent. The EDIINT-Features header indicates the 
capability of the user agent to support the listed feature with its 
trading partner without out-of-band communication and agreement. 


1.1. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. EDIINT-Features Header Syntax 


The EDIINT-Features header can appear in the header section of an 
AS1, AS2, and AS3 message. Its ABNF [RFC5234] syntax is listed 


below. 

Feature = "EDIINT-Features:" [WSP] Feature-Name *([WSP] "," 
[WSP] Feature-Name) 

Feature-Name = 1%*Feature-Token 


$d48-57 / ; 0- 
$d65-90 / ; A- 
%A97-122 / ; a-z 

"—" ; hyphen is allowed 

; blank space " " is not allowed 


Feature-Token 9 
Z 
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The Feature-Token allows for feature names to be specified and can 
only contain alphanumeric characters along with the hyphen. Feature 
names are case insensitive. 


3. Implementation and Processing 


The EDIINT-Features header field indicates the originating user agent 
is capable of supporting the features listed. The EDIINT-Features 
header field MUST be present in all messages transmitted by the user 
agent and not just messages that utilize the feature. Upon 
examination of the EDIINT-Features header field, the trading partner 
SHOULD assume the user agent is capable of receiving messages 
utilizing any of the features listed. 


Features that utilize the EDIINT-Features header field MUST be 
specified in RFCs. These RFCs MUST describe the feature name that is 
listed in the header and the means by which it should be used. 


4. EDIINT Applications 


AS2 and AS3 applications currently use a version header, AS2-Version 
and AS3-Version, respectively, to indicate functional support. The 
EDIINT-Features header field tremendously improves the purpose and 
function of the old version header. However, to provide a connection 
from the old version header and the EDIINT-Features header field, AS2 
and AS3 applications that implement the EDIINT-Features header field 
MUST use the version value of "1.2" to indicate the support of the 
EDIINT-Features header field. Also, since version "1.1" indicates 
the implementation supports compression [RFC5402] and "1.2" builds 
upon "1.1", AS2-Version or AS3-Version of "1.2" MUST support 
compression regardless of whether it is mentioned as a feature in the 
EDIINT-Features header field. 


AS1 does not use a version header and one is not required for 
including the EDIINT-Features header field. 


The EDIINT-Features header field is informational, and AS1, AS2, or 
AS3 trading partners who have not implemented it can safely ignore 
this header. 

5. IANA Considerations 
IANA has registered the following provisional header. 


Header field name: EDIINT-Features 


Applicable protocol: http and mail 
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Status: provisional 


Author/Change controller: Kyle Meadors of Drummond Group 
(kyle@drummondgroup.com) 


Specification document(s): this document 
Related information: This header will be used in conjunction with the 
EDIINT WG specifications RFC 4130 (AS2), RFC 3335 (AS1) and RFC 4823 
(AS3). 

6. Security Considerations 
Because headers are often un-encrypted, it may be possible for the 
EDIINT-Features header field to be altered. Trading partners MAY 
consult out-of-band to confirm feature support. 


7. Normative References 


[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
Requirement Levels", BCP 14, RFC 2119, March 1997. 


[RFC3335] Harding, T., Drummond, R., and C. Shih, "MIME-based Secure 
Peer-to-Peer Business Data Interchange over the Internet", 
RFC 3335, September 2002. 


[RFC4130] Moberg, D. and R. Drummond, "MIME-Based Secure Peer-to- 
Peer Business Data Interchange Using HTTP, Applicability 
Statement 2 (AS2)", RFC 4130, July 2005. 


[RFC4823] Harding, T. and R. Scott, "FTP Transport for Secure Peer- 
to-Peer Business Data Interchange over the Internet", RFC 
4823, April 2007. 


[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 
Specifications: ABNF", STD 68, RFC 5234, January 2008. 


[RFC5402] Harding, T., Ed., "Compressed Data within an Internet 


Electronic Data Interchange (EDI) Message", RFC 5402, 
February 2010. 


Meadors Informational [Page 4] 


RFC 6017 September 2010 


Author’s Address 


Kyle Meadors (editor) 
Drummond Group Inc. 
Nashville, Tennessee 37221 
US 


Phone: +1 (817) 709-1627 
EMail: kyle@drummondgroup.com 


Meadors Informational [Page 5] 


